Order a category listing by the position set in the browsed category - #1289

Why it is a real defect rather than a data quirk

The query is not valid aggregation - it only runs because PrestaShop sets sql_mode = '' in DbPDO.
Asking the same server to apply the standard rejects it outright:

ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP BY clause and contains
nonaggregated column 'prestashop.cp.position' which is not functionally dependent on columns
in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

So which position wins is undefined, not merely unexpected. On the default data set of a 9.1 shop the
server happens to keep the browsed category's row and the listing looks right; forcing the other
candidate rows on the same data gives 16,6,17,7,18,8,… where the merchant's order is
7,6,8,10,9,11,…. That is the same symptom #42279 reports from a production shop, so this fixes a
latent defect whose visibility depends on the plan and the data rather than one that reproduces
everywhere.

The two changes

src/Filters/Products.php pins the ordering:

$positionInCategory = 'MIN(IF(cp.id_category = ' . (int) $query->getIdCategory() . ', cp.position, NULL))';
$orderBy = 'ISNULL(' . $positionInCategory . ') ASC, ' . $positionInCategory;

ISNULL(...) ASC keeps the products that have no position in the browsed category last in both
directions, which a sentinel value would not do on DESC.

src/Adapter/MySQL.php stops pushing an expression order field into the initial population.
computeOrderByField() already treats a value containing ( as an outer-query expression and returns
it untouched, but it had added it to the initial population's select list first. The initial population
does not carry the outer query's joins, so the expression there refers to tables that are not joined at
that level. Any caller passing an expression hits this, not just this one.